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CAPÍTULO 5 


PROGRAMAÇÃO ORIENTADA A OBJETOS [HS 


No mundo em que vivemos, de constante utilização e atualização de recursos 
tecnológicos, os softwares ganharam um espaço que vem aumentando vertiginosamente e 
em diversos setores da sociedade. Existem programas específicos para uso comercial, 
industrial, administrativo, financeiro, governamental, militar, científico, de entretenimento 
etc. Para atender a essa demanda cada vez maior e mais exigente, as áreas de 
desenvolvimento e manutenção de softwares precisam criar aplicações cada vez mais 
complexas. 

Programação Orientada a Objetos (OOP ou POO) é um paradigma de programação 
modular que visualiza o programa como um conjunto de objetos que interagem entre si por 
meio de ações (definidas por métodos), ou seja, é uma técnica de desenvolvimento de 
softwares que consiste em representar os elementos do mundo real (que pertencem ao 
escopo da aplicação) dentro do software. Possui uma série de regras e convenções que 
padronizam as aplicações orientadas a objetos e que possibilitam o uso de todos os recursos 
inerentes a essa técnica. 

A orientação a objetos surgiu da necessidade de elaborar programas mais 
independentes, de forma ágil, segura e descentralizada, permitindo que equipes de 
programadores localizadas em qualquer parte do mundo trabalhem no mesmo projeto. Essa 
técnica de desenvolvimento de softwares, mais próxima do ponto de vista humano, torna 
mais simples e natural o processo de análise de problemas cotidianos e a construção de 
aplicações para solucioná-los. 

Para que isso seja possível, é preciso quebrar paradigmas em relação ao modelo 
procedural, que tem como base a execução de rotinas ou funções sequenciadas e ordenadas 
para atender aos requisitos funcionais de uma aplicação. Nele, as regras (codificação) ficam 
separadas dos dados (informações processadas). Por isso, o programador passou a 
estruturar a aplicação para que, além de resolver problemas para os quais foi desenvolvido, 
o software possa interligar elementos como programação, banco de dados, conectividade em 
rede, gerenciamento de memória, segurança etc. Isso aumenta signifi cativamente a 
complexidade na elaboração e expansão desses softwares. 

A técnica de programação procedural leva o desenvolvedor a decompor o sistema em 
partes menores (funções), criando um emaranhado de inúmeras funções que chamam umas 
às outras. Geralmente não há separação de conceitos e responsabilidades, causando 
dependências enormes no sistema, dificultando futuras manutenções no código do 
programa. Não existe muito reaproveitamento de código, ao contrário, muitas vezes se tem 
muito código duplicado. 

Consideremos o clássico problema da validação de um CPF. Normalmente, temos um 
formulário, no qual recebemos essa informação, e depois temos que enviar esses caracteres 
para uma função que irá validá-lo. 


CPF: | —+ 
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Há obrigatoriedade de validar esse CPF? Podemos esquecer de chamar esse validador 
inúmeras vezes. Imagine que temos 100 formulários e precisemos validar em todos eles o 
CPF. Se a equipe tem 3 programadores trabalhando nesses formulários, todos serão 
responsáveis por essa validação. 

A situação pode piorar: na entrada de um novo desenvolvedor, precisaríamos avisá-lo 
que sempre devemos validar o CPF de um formulário. É nesse momento que nascem 
aqueles guias de programação para o desenvolvedor. Em outras palavras, todo 
desenvolvedor deverá saber sobre uma quantidade enorme de informações que, na maioria 
das vezes, não está realmente relacionado à sua parte no sistema, mas ele precisa saber 
tudo isso, resultando um entrave muito grande. 

Ainda temos outro problema: imagine que em todo formulário, precisamos também 
validar a idade do cliente - precisa ser maior de 18 anos. Precisamos colocar um if, mas 
onde? Espalhado por todo o código e mesmo que se crie outra função para validar, 
precisaremos incluir isso nos nossos 100 formulários já existentes. Qual é a chance de 
esquecermos em um deles? É muito grande. 

Seria interessante poder concentrar essa responsabilidade em apenas um lugar, para 
não ter chances de esquecer isso. Melhor ainda seria se conseguissemos mudar essa 
validação e os outros programadores nem precisassem ficar sabendo disso. Em outras 
palavras, eles criariam formulários e um único programador seria responsável pela 
validação: os outros nem sabem da existência desse trecho de código. 

O paradigma da Orientação a Objetos eleva a programação e o desenvolvimento de 
sistemas para um novo patamar, permitindo a criação de programas componentizados, 
separando as partes do sistema por responsabilidades e fazendo com que essas partes se 
comuniquem entre si, por meio de mensagens. A Orientação a objetos vai nos ajudar em 
muito em se organizar e escrever menos código, além de concentrar as responsabilidades 
nos pontos certos, flexibilizando sua aplicação, encapsulando a lógica de negócios. 

O modelo orientado a objetos tem como base a execução de métodos (pequenas funções) 

que atuam diretamente sobre os dados de um objeto, levando em conta o modo como o 
usuário enxerga os elementos tratados no mundo real. Nessa técnica, o desenvolvedor cria 
uma representação do que se pretende gerenciar no sistema (um cliente, um produto, um 
funcionário, por exemplo) exatamente como acontece no mundo real. Assim, esses 
elementos podem interagir, trocando informações e adotando ações que definem os 
processos a serem gerenciados pelo sistema. Por exemplo, no processo de venda de uma 
empresa podem ocorrer os seguintes passos: um cliente compra um ou vários produtos; o 
cliente é atendido por um vendedor; o vendedor tem direito a comissão. 

Ao analisarmos esses processos no mundo real, destacamos como “entidades” 
envolvidas os seguintes elementos: cliente, vendedor e produto, assim como a venda e o 
cálculo e comissão. A partir da análise orientada a objetos, representamos essas entidades 
dentro da nossa aplicação com as mesmas características adotadas no mundo real (nome, 
endereço e telefone de um cliente, etc. além de suas atitudes típicas numa transação 
comercial (cotação, compra, pagamento etc.). 


A Orientação a Objetos é mais intuitiva e fácil de aprender do que as técnicas 
tradicionais, pois foca o problema em conceitos do mundo real. Dentre as vantagens que a 
Orientação a Objetos proporciona, podemos destacar: 

« Aumento de produtividade 
« Reuso de código 


Sa = a = = n"nnnha 


CECOia Piciiei ESA DiL PROCESSOR Material do Curso Técnico em Informática 
HORÁCIO AUGUSTO DA SILVEIRA Desenvolvimento de Software I 
= Redução das linhas de código programadas 
« Separação de responsabilidades 
= (Componentização 
« Maior flexibilidade do sistema 


5.1. Escalabilidade 


= Facilidade na manutenção, dentre outras vantagens. 


5.2. UNIFIED MODELING LANGUAGE 


A UML, sigla em inglês de linguagem modular unifi cada, é dedicada à especificação, 
visualização, construção e documentação que usa notação gráfica para modelar softwares. 
Muito utilizada em empresas que desenvolvem aplicações orientadas a objetos, também 
está presente em várias publicações relacionadas com a linguagem Java (além de ser um 
instrumento interessante para elaboração de exercícios em aula). Por isso, escolhemos um 
de seus diagramas (de classes) para ilustrar nossos exemplos. É bom frisar, no entanto, que 
os recursos da UML vão muito além desses diagramas. 





A UML — Unified Modeling Language ou Linguagem de Modelagem Unificada — é uma 
linguagem visual utilizada para modelar softwares baseados no paradigma de orientação a 
objetos. É uma linguagem de modelagem de propósito geral que pode ser aplicada a todos os 
domínios de aplicação. Essa linguagem tornou-se, nos últimos anos, a linguagem-padrão de 
modelagem adotada internacionalmente pela indústria de engenharia de software. 


UNIFIED 
MODELING 
LANGUAGE 





Antigamente não havia uma forma padrão de se analisar e modelar sistemas 
orientados a objetos. Diferentes metodologias levavam a um desentendimento e confusão 
por parte de analistas e desenvolvedores, por suas diferentes características, elementos 
conceituais e notação. Algumas metodologias eram boas em determinadas características, 
mas ruins ou inexistentes em outras necessidades da análise e modelagem orientada a 
objetos. 

Grady Booch, James Rumbaugh e Ivar Jacobson se juntaram, unificaram suas 
metodologias e criaram a UML em 1996, pegando o melhor de cada metodologia e 
melhorando com o suporte e ajuda da comunidade. Tão logo a primeira versão foi lançada, 
muitas empresas atuantes na área de modelagem e desenvolvimento de software passaram 
a contribuir para o projeto, fornecendo sugestões para melhorar e ampliar a linguagem. 
Finalmente, a UML foi adotada, em 1997, pela OMG (Object Management Group ou Grupo 
de Gerenciamento de Objetos), como uma linguagem-padrão de modelagem. 
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5.1.1. Por que modelar softwares? 


Muitos “profissionais” podem afirmar que conseguem determinar todas as 
necessidades de um sistema de informação de cabeça, e que sempre trabalharam assim. 
Qual a real necessidade de se projetar uma casa? Um pedreiro experiente não é capaz de 
construí-la sem um projeto? Isso pode ser verdade, mas a questão é muito mais ampla, 
envolvendo fatores extremamente complexos, como levantamento e análise de requisitos, 
prototipação, tamanho do projeto, complexidade, prazos, custos, documentação, manutenção 
e reusabilidade, entre outros. 

Existe uma diferença gritante entre construir uma pequena casa e construir um prédio 
de vários andares. Obviamente, para se construir um edifício é necessário, em primeiro 
lugar, desenvolver um projeto muito bem-elaborado, cujos cálculos têm de estar 
extremamente corretos e precisos. Além disso, é preciso fornecer uma estimativa de custos, 
determinar em quanto tempo a construção estará concluída, avaliar a quantidade de 
profissionais necessária à execução da obra, especificar a quantidade de material a ser 
adquirida para a construção, escolher o local onde o prédio será erguido etc. Grandes 
projetos não podem ser modelados de cabeça, nem mesmo a maioria dos pequenos projetos 
pode sê-lo, exceto, talvez, aqueles extremamente simples. 

Na realidade, por mais simples que seja, todo e qualquer sistema deve ser modelado 
antes de se iniciar sua implementação, entre outras coisas, porque os sistemas de 
informação frequentemente costumam ter a propriedade de “crescer”, isto é, aumentar em 
tamanho, complexidade e abrangência. Muitos profissionais costumam afirmar que 
sistemas de informação são “vivos”, porque nunca estão completamente finalizados. Na 
verdade, o termo correto seria “dinâmicos”, pois normalmente os sistemas de informação 
estão em constante mudança. 

Assim, um sistema de informação precisa ter uma documentação extremamente 
detalhada, precisa e atualizada para que possa ser mantido com facilidade, rapidez e 
correção, sem produzir novos erros ao corrigir os antigos. Modelar um sistema é uma forma 
bastante eficiente de documentá-lo, mas a modelagem não serve apenas para isso: a 
documentação é apenas uma das vantagens fornecidas pela modelagem. 

Resumindo, desenvolver o modelo de uma aplicação antes de construí-la, é tão 
essencial quanto ter uma planta para a construção de uma casa. Bons modelos são 
essenciais para a comunicação entre as equipes de projetos e para assegurar a beleza 
arquitetural e, com o aumento da complexidade dos sistemas, é importância conhecer boas 
técnicas de modelagem. 


5.2.1. Diagrama de Classes 


Como vimos, a UML é uma linguagem de modelagem de sistemas, usada para 
especificar, modelar, visualizar e documentar os modelos e artefatos de sistemas orientados 
a objetos baseando-se em diagramas. 

O diagrama de classes é provavelmente o mais utilizado e é um dos mais importantes 
da UML. Serve de apoio para a maioria dos demais diagramas. Como o próprio nome diz, 
define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos 
que cada classe tem, além de estabelecer como as classes se relacionam e trocam 
informações entre si. 

As classes podem implementar uma ou mais interfaces e, graficamente, são 
representadas por retângulos, com três divisões: Nome da Classe, Conjunto de Atributos e 
Conjunto de Métodos. 
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- tempoGasto : double 
- velocMedia : int 


+ distancia () : double 
+ litrosUsados () : double 





5.3. OBJETOS 





Os elementos fundamentais da Programação Orientada a Objetos (POO) são 
denominados, apropriadamente, de objetos. Quando olhamos ao nosso redor e tudo o que 
vemos são objetos: carro, mesa, janela, livro, pessoa, etc. 

Para a programação, um objeto é qualquer elemento do mundo real que pode ser 
compreendido e, portanto, descrito dentro de um contexto. Assim, objetos são estruturas de 
programas que possuem suas próprias características (dados) e que interagem com outros 
objetos (realizam ações). 

Na Orientação a Objetos, a execução de um programa é baseada nas interações entre 
objetos, sendo necessário conhecer e descrever estes objetos. Essa descrição caracteriza a 
parte mais difícil da orientação a objetos, pois depende da perspectiva e experiência do 
profissional. 





Para descrever um objeto é necessário conhecer: 


= Identidade (quem é): Todo objeto é único e identificável, sendo necessário diferenciar 
um objeto dos outros. 


« Estado (como é): Conjunto de valores dos atributos em determinado instante. Seria a 
aparência do objeto, como por exemplo cor azul, tempo 9.9 e velocidade máxima 300, etc. 


= Comportamento (o que faz): Conjunto de métodos que definem suas possíveis ações 
como, por exemplo, calcular, correr, parar, etc. 
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O objeto da figura é identificado como “meu carro”. A identidade deve permitir associar 
a descrição com o objeto, pois “Porsche Carrera GT” é a marca e modelo do objeto, não 
devendo ser utilizado como identidade para não confundi-lo com outros “Porsches”. 





O estado exibe as características conhecidas do objeto, como a marca/modelo, 
velocidade, cor, etc. São as coisas que um objeto conhece sobre ele e podem ter valores 
exclusivos para cada objeto. 


Identidade: 


Porsche Carrera GT 

O a 200 Km/h em 9.9 s 
300 Km/h 

Prata 


Estado: 


ligar, acelerar, 
brecar, correr 


Comportamento: 





O comportamento indica o que o objeto pode fazer e para que será utilizado, como 
ligar, acelerar, brecar e correr. 


5.4. CLASSES 





Uma classe descreve um conjunto de entidades (reais ou abstratas) do mesmo tipo e 
com as mesmas características e comportamento e define a estrutura e o comportamento 
dos objetos daquele determinado tipo. 

Por definição, uma classe é um modelo (protótipo) que define as variáveis (estado) e os 
métodos (comportamento) comuns a todos os objetos do mesmo tipo. 
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Classe Objeto 


Podemos dizer que as classes são, na verdade, modelos de objetos do mesmo tipo e não 
são usadas diretamente. A Classe é a descrição genérica de todos os objetos semelhantes: 
todos os objetos semelhantes ao Porsche Carrera GT são carros, portanto Porsche Carrera 
GT é um objeto que pertence a classe dos Carros. 

Uma classe não é um objeto, mas é usada para construí-los. Ela informa à JVM como 
criar um objeto desse tipo específico. Cada objeto criado a partir dessa classe terá seus 
próprios valores para as variáveis de instância da classe. 

As classes de modelagem podem ser comparadas a moldes ou formas que definem as 
características e os comportamentos dos objetos criados a partir delas. Vale traçar um 
paralelo com o projeto de um automóvel. Os engenheiros definem as medidas, a quantidade 
de portas, a potência do motor, a capacidade em relação ao número de passageiros, a 
localização do estepe, dentre outras descrições necessárias para a fabricação de um veículo. 

Durante a elaboração do projeto, é óbvio que o automóvel ainda não existe. Porém, 
quando for fabricado, todas as especificações previamente definidas no desenho terão de ser 
seguidas à risca. Os diferentes modelos desse mesmo veículo terão detalhes diferenciais, 
como cor da lataria, tipo das rodas, material do banco, acessórios etc. Nada, entretanto, que 
altere as características originais, como um todo. 

Serão informações acrescentadas aos elementos já definidos no projeto (atributos). O 
funcionamento básico do automóvel também foi definido no projeto. O motorista poderá 
acelerar, frear, trocar marchas, manobrar etc. Essas ações, assim como a respectiva 
resposta do carro (métodos), permitem uma outra analogia com nosso assunto. O motorista 
(que seria no nosso caso o programador) não precisa ter conhecimentos profundos sobre 
mecânica para, por exemplo, acelerar o automóvel. Internamente, o veículo possui um 
complexo mecanismo que aciona as partes responsáveis pela injeção e pela combustão. Esta, 
por sua vez, gera uma pressão sobre outras engrenagens do motor, impulsionando as rodas 
e fazendo o carro se deslocar — processos também especificados no projeto. Para o motorista, 
quando o objetivo é velocidade, basta saber que é preciso pisar no pedal do acelerador e que 
quanto mais pressão for feita mais rápido andará o veículo. Resumindo: para uso diário do 
automóvel (objeto) não é preciso conhecer detalhes de como o funcionamento dos 
mecanismos foi definido no projeto (classe). Basta operá-los (chamar os métodos, 
obedecendo à sua assinatura — como veremos, em seguida). Da mesma forma, o 
programador não precisa saber, em detalhes, como a classe System, por exemplo, foi 
desenvolvida, mas sim saber como utilizá-la para apresentar uma informação na tela. 


Pa Dou nfnfnii 


ESCOLA TÉCNICA ESTADUAL PROFESSOR Material do Curso Técnico em Informática 
HORÁCIO AUGUSTO DA SILVEIRA Desenvolvimento de Software I 


modelo: | Porsche Carrera GT 
t(0a 200): ]9.9s 
vel. máxima: | 300 Km/h 
cor: 
Motor: 
potência: 


ligar () | ligar () 
Comportamento: acelerar ( ) | acelerar () 
brecar () | brecar () 









3.3.1. Descrição de classes 
Para descrever uma classe é necessário conhecer o que será relevante para se 
trabalhar com o objeto: 


= Identidade (TIPO): Representa o tipo no qual o objeto é classificado, como Carro, 
Pessoa, Cliente, etc. 


= Estado (DADOS): Conjunto de atributos que permitem descrever o objeto: cor, tempo, 
velocidade, ... 


= Comportamento (o que faz): Implementação dos métodos que definem suas possíveis 
ações, tais como: calcular, correr, ... 





- modelo : String 
- velocidade : int 


- cor: String 


+ ligar () : void 
+ acelerar () : void 
+ freiar () : void 





A classificação do objeto em uma classe é um dos passos mais importantes da POO, 
pois a classe é a representação que será implementada em tempo de projeto com o 
objetivo de obter o objeto em tempo de execução. 


5.5. MODIFICADORES DE ACESSO 


Os modificadores de acesso indicam como os atributos, métodos e construtores podem ser 
utilizados por outras classes. Podem ser: 


« Public (+): Permite a todos acessarem um determinado atributo ou método. 
« Protected (4): É acessível somente pela própria classe e subclasses (herança). 
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« Package (-): E acessível somente pelas classes do pacote que a contém. 
« Private (-): É acessível somente pela própria classe. Atributos ou métodos não podem 
ser acessados de fora da classe, ou seja, não podem ser modificados. 


5.6. MÉTODOS 


O modelo orientado a objetos tem como base a execução de métodos (pequenas funções) 
que atuam diretamente sobre os dados de um objeto, levando em conta o modo como o 
usuário enxerga os elementos tratados no mundo real. Nessa técnica, o desenvolvedor cria 
uma representação do que se pretende gerenciar no sistema (um cliente, um produto, um 
funcionário, por exemplo) exatamente como acontece no mundo real. Assim, esses 
elementos podem interagir, trocando informações e adotando ações que definem os 
processos a serem gerenciados pelo sistema. Por exemplo, no processo de venda de uma 
empresa podem ocorrer os seguintes passos: um cliente compra um ou vários produtos; o 
chente é atendido por um vendedor; o vendedor tem direito a comissão. 


Atributos 

As informações (dados) que definem as características e os valores pertinentes à classe 
e que serão armazenados nos (futuros) objetos são chamadas de atributos. 

Também são conhecidos como variáveis de instância. Para não confundir com variáveis 
comuns, vamos chamá-los sempre de atributos. 


Métodos 

Métodos são blocos de código que pertencem a uma classe e têm por finalidade realizar 
tarefas. Geralmente, correspondem a uma ação do objeto. Considerando-se o exemplo do 
automóvel, os métodos poderiam definir processos como ligar, acelerar, frear etc. 


5.7. ABSTRAÇÃO 


Abstração é a habilidade e a capacidade de se modelar conceitos, entidades, elementos, 
problemas e características do mundo real, de um domínio do problema em questão, 
levando-se em conta apenas os detalhes importantes para a resolução do problema e 
desprezando coisas que não têm importância no contexto. 

Se pensarmos no conceito de “conta corrente” bancária e abstrairmos este conceito, 
podemos identificar detalhes comuns, como o número da conta, número da agência e saldo; 
e operações como débito em conta, depósito e extrato da conta. Basicamente essas são as 
características de conta corrente para todos os bancos, apesar de um ou outro banco ter uma 
política de descontos de taxas etc. 

Abstração é a capacidade do ser humano de se concentrar nos aspectos essenciais de 





um contexto qualquer, ignorando características menos importantes ou acidentais. 
Outra definição: habilidade mental que permite visualizar os problemas do mundo real 
com vários graus de detalhe, dependendo do contexto do problema. 


Sra E = = wu n“ninha 


ESCOLA TÉCNICA ESTADUAL PROFESSOR Material do Curso Técnico em Informática 
HORÁCIO AUGUSTO DA SILVEIRA Desenvolvimento de Software I 


Para o programador que utiliza orientação a objetos, a abstração é a habilidade de 
extrair do mundo real os elementos (entidades, características, comportamentos, 
procedimentos) que realmente interessam para a aplicação desenvolvida. 

Por exemplo, as informações relevantes a respeito de um CD para uma aplicação 


usada no gerenciamento de uma loja que vende CDs, são diferentes das de uma aplicação 
para o gerenciamento de uma fábrica, que produz CDs. 
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